<!DOCTYPE html>
<html lang="zh-CN">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>《技术领导力：程序员如何才能带团队》读书笔记 | Brennan&#39;s blog</title>
    <meta name="generator" content="VuePress 1.9.5">
    <link rel="icon" href="/brennan-wu-blog/img/favicon.ico">
    <meta name="description" content="web前端技术博客,专注web前端学习与总结。JavaScript,js,ES6,TypeScript,vue,React,python,css3,html5,Node,git,github等技术文章。">
    <meta name="keywords" content="前端博客,个人技术博客,前端,前端开发,前端框架,web前端,前端面试题,技术文档,学习,面试,JavaScript,js,ES6,TypeScript,vue,python,css3,html5,Node,git,github,markdown">
    <meta name="baidu-site-verification" content="7F55weZDDc">
    <meta name="theme-color" content="#11a8cd">
    
    <link rel="preload" href="/brennan-wu-blog/assets/css/0.styles.6d0ebdc8.css" as="style"><link rel="preload" href="/brennan-wu-blog/assets/js/app.422e2e24.js" as="script"><link rel="preload" href="/brennan-wu-blog/assets/js/2.372f0770.js" as="script"><link rel="preload" href="/brennan-wu-blog/assets/js/3.22a0f36b.js" as="script"><link rel="preload" href="/brennan-wu-blog/assets/js/27.b3041988.js" as="script"><link rel="prefetch" href="/brennan-wu-blog/assets/js/10.9b0e0932.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/11.389398e0.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/12.c046ebcf.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/13.ebdfb480.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/14.f75b9d1c.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/15.d20a3fd0.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/16.3816d4a5.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/17.bbbea7a6.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/18.214ef1b5.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/19.0363e8ba.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/20.a38f522d.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/21.6b18ffad.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/22.5c3876be.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/23.dcf195c4.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/24.7e75542f.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/25.9d5b9250.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/26.040652ab.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/28.d5292c46.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/29.7ced233f.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/30.4856fc6c.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/31.0e508fe6.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/32.54efed0e.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/33.89aebe9c.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/34.124399ef.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/35.b1225438.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/36.8909f7ca.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/37.8321b812.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/38.4b637941.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/39.119a3f2c.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/4.28226b98.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/40.9624480f.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/41.df28c0a9.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/42.33d89136.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/43.04ab01ff.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/44.867b4caf.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/45.1337d2e2.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/5.e01b5955.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/6.4fe91b18.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/7.c836dcbd.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/8.85621850.js"><link rel="prefetch" href="/brennan-wu-blog/assets/js/9.5c2abfd9.js">
    <link rel="stylesheet" href="/brennan-wu-blog/assets/css/0.styles.6d0ebdc8.css">
  </head>
  <body class="theme-mode-light">
    <div id="app" data-server-rendered="true"><div class="theme-container sidebar-open have-rightmenu"><header class="navbar blur"><div title="目录" class="sidebar-button"><svg xmlns="http://www.w3.org/2000/svg" aria-hidden="true" role="img" viewBox="0 0 448 512" class="icon"><path fill="currentColor" d="M436 124H12c-6.627 0-12-5.373-12-12V80c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12zm0 160H12c-6.627 0-12-5.373-12-12v-32c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12zm0 160H12c-6.627 0-12-5.373-12-12v-32c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12z"></path></svg></div> <a href="/brennan-wu-blog/" class="home-link router-link-active"><img src="/brennan-wu-blog/img/logo.png" alt="Brennan's blog" class="logo"> <span class="site-name can-hide">Brennan's blog</span></a> <div class="links"><div class="search-box"><input aria-label="Search" autocomplete="off" spellcheck="false" value=""> <!----></div> <nav class="nav-links can-hide"><div class="nav-item"><a href="/brennan-wu-blog/" class="nav-link">首页</a></div><div class="nav-item"><a href="/brennan-wu-blog/study/" class="nav-link">学习笔记</a></div><div class="nav-item"><a href="/brennan-wu-blog/grow/" class="nav-link">成长笔记</a></div><div class="nav-item"><a href="/brennan-wu-blog/read/" class="nav-link">读书笔记</a></div><div class="nav-item"><div class="dropdown-wrapper"><button type="button" aria-label="收藏导航" class="dropdown-title"><a href="/brennan-wu-blog/collection/" class="link-title">收藏导航</a> <span class="title" style="display:none;">收藏导航</span> <span class="arrow right"></span></button> <ul class="nav-dropdown" style="display:none;"><li class="dropdown-item"><!----> <a href="/brennan-wu-blog/pages/527bc4/" class="nav-link">我的导航</a></li><li class="dropdown-item"><!----> <a href="/brennan-wu-blog/pages/c8836a/" class="nav-link">我的收藏</a></li></ul></div></div><div class="nav-item"><div class="dropdown-wrapper"><button type="button" aria-label="索引" class="dropdown-title"><a href="/brennan-wu-blog/archives/" class="link-title">索引</a> <span class="title" style="display:none;">索引</span> <span class="arrow right"></span></button> <ul class="nav-dropdown" style="display:none;"><li class="dropdown-item"><!----> <a href="/brennan-wu-blog/categories/" class="nav-link">分类</a></li><li class="dropdown-item"><!----> <a href="/brennan-wu-blog/tags/" class="nav-link">标签</a></li><li class="dropdown-item"><!----> <a href="/brennan-wu-blog/archives/" class="nav-link">归档</a></li></ul></div></div> <!----></nav></div></header> <div class="sidebar-mask"></div> <div class="sidebar-hover-trigger"></div> <aside class="sidebar" style="display:none;"><div class="blogger"><img src="/brennan-wu-blog/img/logo.png"> <div class="blogger-info"><h3>Brennan Wu</h3> <span>过度忙碌使你落后，有空别忘了给自己充电!</span></div></div> <nav class="nav-links"><div class="nav-item"><a href="/brennan-wu-blog/" class="nav-link">首页</a></div><div class="nav-item"><a href="/brennan-wu-blog/study/" class="nav-link">学习笔记</a></div><div class="nav-item"><a href="/brennan-wu-blog/grow/" class="nav-link">成长笔记</a></div><div class="nav-item"><a href="/brennan-wu-blog/read/" class="nav-link">读书笔记</a></div><div class="nav-item"><div class="dropdown-wrapper"><button type="button" aria-label="收藏导航" class="dropdown-title"><a href="/brennan-wu-blog/collection/" class="link-title">收藏导航</a> <span class="title" style="display:none;">收藏导航</span> <span class="arrow right"></span></button> <ul class="nav-dropdown" style="display:none;"><li class="dropdown-item"><!----> <a href="/brennan-wu-blog/pages/527bc4/" class="nav-link">我的导航</a></li><li class="dropdown-item"><!----> <a href="/brennan-wu-blog/pages/c8836a/" class="nav-link">我的收藏</a></li></ul></div></div><div class="nav-item"><div class="dropdown-wrapper"><button type="button" aria-label="索引" class="dropdown-title"><a href="/brennan-wu-blog/archives/" class="link-title">索引</a> <span class="title" style="display:none;">索引</span> <span class="arrow right"></span></button> <ul class="nav-dropdown" style="display:none;"><li class="dropdown-item"><!----> <a href="/brennan-wu-blog/categories/" class="nav-link">分类</a></li><li class="dropdown-item"><!----> <a href="/brennan-wu-blog/tags/" class="nav-link">标签</a></li><li class="dropdown-item"><!----> <a href="/brennan-wu-blog/archives/" class="nav-link">归档</a></li></ul></div></div> <!----></nav>  <ul class="sidebar-links"><li><section class="sidebar-group collapsable depth-0"><p class="sidebar-heading"><span>个人成长</span> <span class="arrow right"></span></p> <!----></section></li><li><section class="sidebar-group collapsable depth-0"><p class="sidebar-heading open"><span>专业技术</span> <span class="arrow down"></span></p> <ul class="sidebar-links sidebar-group-items"><li><a href="/brennan-wu-blog/pages/b08d0e/" class="sidebar-link">《软技能-代码之外的生存指南》读书笔记</a></li><li><a href="/brennan-wu-blog/pages/2ffcfe/" aria-current="page" class="active sidebar-link">《技术领导力：程序员如何才能带团队》读书笔记</a><ul class="sidebar-sub-headers"><li class="sidebar-sub-header level2"><a href="/brennan-wu-blog/pages/2ffcfe/#第1章-技术管理工作" class="sidebar-link">第1章 技术管理工作</a><ul class="sidebar-sub-headers"><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_1-1技术管理" class="sidebar-link">1.1技术管理</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_1-2-技术团队领导者" class="sidebar-link">1.2 技术团队领导者</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#工作职责定位" class="sidebar-link">工作职责定位</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#工作品质定位" class="sidebar-link">工作品质定位</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_1-3-带领技术团队心得" class="sidebar-link">1.3 带领技术团队心得</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#自主循环" class="sidebar-link">自主循环</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#技术人员心态成长四阶段" class="sidebar-link">技术人员心态成长四阶段</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#找到属于自己的圈子" class="sidebar-link">找到属于自己的圈子</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#何时成为技术管理者" class="sidebar-link">何时成为技术管理者</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_1-4-个人职业发展" class="sidebar-link">1.4 个人职业发展</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#对于职业的选择" class="sidebar-link">对于职业的选择</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#工程师的等级" class="sidebar-link">工程师的等级</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#不要计较当下职位" class="sidebar-link">不要计较当下职位</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#坚持做正确的技术管理" class="sidebar-link">坚持做正确的技术管理</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#抛弃通道思维-建立雷达视角" class="sidebar-link">抛弃通道思维，建立雷达视角</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#职业生涯的收入趋势" class="sidebar-link">职业生涯的收入趋势</a></li></ul></li><li class="sidebar-sub-header level2"><a href="/brennan-wu-blog/pages/2ffcfe/#第2章-团队管理、人员管理" class="sidebar-link">第2章 团队管理、人员管理</a><ul class="sidebar-sub-headers"><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_2-1-管理基础" class="sidebar-link">2.1 管理基础</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#什么是管理" class="sidebar-link">什么是管理</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#团队成员品质" class="sidebar-link">团队成员品质</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_2-2-组建团队" class="sidebar-link">2.2 组建团队</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#招聘策略" class="sidebar-link">招聘策略</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#面试技巧" class="sidebar-link">面试技巧</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#性格分析" class="sidebar-link">性格分析</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#人员分类" class="sidebar-link">人员分类</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#新员工入职" class="sidebar-link">新员工入职</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_2-3-管理团队" class="sidebar-link">2.3 管理团队</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#向下管理" class="sidebar-link">向下管理</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#向上管理" class="sidebar-link">向上管理</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#对外管理" class="sidebar-link">对外管理</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#自我管理" class="sidebar-link">自我管理</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_2-4-影响团队因素" class="sidebar-link">2.4 影响团队因素</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#不懂技术的技术领导" class="sidebar-link">不懂技术的技术领导</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#薪资管理" class="sidebar-link">薪资管理</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#上升通道" class="sidebar-link">上升通道</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#大规模变革" class="sidebar-link">大规模变革</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#一言堂" class="sidebar-link">一言堂</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#频繁开会" class="sidebar-link">频繁开会</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#老员工的管理" class="sidebar-link">老员工的管理</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#工作时间" class="sidebar-link">工作时间</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#缺乏愿景" class="sidebar-link">缺乏愿景</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_2-5-其他相关知识" class="sidebar-link">2.5 其他相关知识</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#理解程序员工作" class="sidebar-link">理解程序员工作</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#杰出的程序员" class="sidebar-link">杰出的程序员</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#扁平化管理" class="sidebar-link">扁平化管理</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#团建活动的技巧" class="sidebar-link">团建活动的技巧</a></li></ul></li><li class="sidebar-sub-header level2"><a href="/brennan-wu-blog/pages/2ffcfe/#第3章-产品开发过程管理" class="sidebar-link">第3章 产品开发过程管理</a><ul class="sidebar-sub-headers"><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_3-1-开发经理介绍" class="sidebar-link">3.1 开发经理介绍</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#开发经理职务描述" class="sidebar-link">开发经理职务描述</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#开发经理的主要任务" class="sidebar-link">开发经理的主要任务</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#开发经理素质" class="sidebar-link">开发经理素质</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_3-2-产品开发过程管理" class="sidebar-link">3.2 产品开发过程管理</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#项目启动会" class="sidebar-link">项目启动会</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#用户需求-产品需求" class="sidebar-link">用户需求&amp;产品需求</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#总体设计" class="sidebar-link">总体设计</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#概要设计" class="sidebar-link">概要设计</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#详细设计" class="sidebar-link">详细设计</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#编写代码" class="sidebar-link">编写代码</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#代码审核" class="sidebar-link">代码审核</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#单元测试" class="sidebar-link">单元测试</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#集成测试" class="sidebar-link">集成测试</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#系统测试" class="sidebar-link">系统测试</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#产品发布" class="sidebar-link">产品发布</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#开发过程复盘" class="sidebar-link">开发过程复盘</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_3-3-产品开发过程杂谈" class="sidebar-link">3.3 产品开发过程杂谈</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#理解业务的重要性" class="sidebar-link">理解业务的重要性</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#应对需求变更" class="sidebar-link">应对需求变更</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#开发进度管理" class="sidebar-link">开发进度管理</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#评审的重要性" class="sidebar-link">评审的重要性</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#优先级安排" class="sidebar-link">优先级安排</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#项目管理重要性" class="sidebar-link">项目管理重要性</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#产品质量的重要性" class="sidebar-link">产品质量的重要性</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#测试驱动开发" class="sidebar-link">测试驱动开发</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#编写高质量代码的难度" class="sidebar-link">编写高质量代码的难度</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#事必躬亲的错误" class="sidebar-link">事必躬亲的错误</a></li></ul></li><li class="sidebar-sub-header level2"><a href="/brennan-wu-blog/pages/2ffcfe/#第4章-技术调研-预研" class="sidebar-link">第4章 技术调研&amp;预研</a><ul class="sidebar-sub-headers"><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_4-1-概述" class="sidebar-link">4.1 概述</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#技术调研和预研的差别" class="sidebar-link">技术调研和预研的差别</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#参与调研和预研的重要性" class="sidebar-link">参与调研和预研的重要性</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_4-2-技术调研" class="sidebar-link">4.2 技术调研</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#技术调研思路" class="sidebar-link">技术调研思路</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#调研过程" class="sidebar-link">调研过程</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_4-3-技术预研" class="sidebar-link">4.3 技术预研</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#技术预研思路" class="sidebar-link">技术预研思路</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#预研过程" class="sidebar-link">预研过程</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_4-4-其他相关讨论" class="sidebar-link">4.4 其他相关讨论</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#对技术发展的预估" class="sidebar-link">对技术发展的预估</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#开源的好处" class="sidebar-link">开源的好处</a></li></ul></li><li class="sidebar-sub-header level2"><a href="/brennan-wu-blog/pages/2ffcfe/#第5章-系统架构" class="sidebar-link">第5章 系统架构</a><ul class="sidebar-sub-headers"><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_5-1-系统架构工作" class="sidebar-link">5.1 系统架构工作</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#软件架构概念" class="sidebar-link">软件架构概念</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#软件架构师岗位" class="sidebar-link">软件架构师岗位</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#软件架构师的责任" class="sidebar-link">软件架构师的责任</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#软件架构思路" class="sidebar-link">软件架构思路</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#软件架构落地" class="sidebar-link">软件架构落地</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_5-2-系统架构能力培养" class="sidebar-link">5.2 系统架构能力培养</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#提升驱动力" class="sidebar-link">提升驱动力</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#学习能力" class="sidebar-link">学习能力</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#创新思维" class="sidebar-link">创新思维</a></li><li class="sidebar-sub-header level3"><a href="/brennan-wu-blog/pages/2ffcfe/#_5-3-常见问题分析" class="sidebar-link">5.3 常见问题分析</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#无从入手" class="sidebar-link">无从入手</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#技术优先" class="sidebar-link">技术优先</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#业务困境" class="sidebar-link">业务困境</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#一步到位思想" class="sidebar-link">一步到位思想</a></li><li class="sidebar-sub-header level4"><a href="/brennan-wu-blog/pages/2ffcfe/#系统过度设计问题" class="sidebar-link">系统过度设计问题</a></li></ul></li></ul></li><li><a href="/brennan-wu-blog/pages/3b0243/" class="sidebar-link">《程序员修炼之道：从小工到专家》读书笔记</a></li><li><a href="/brennan-wu-blog/pages/c002a8/" class="sidebar-link">《从技术走向管理：李元芳履职记》读书笔记</a></li></ul></section></li><li><section class="sidebar-group collapsable depth-0"><p class="sidebar-heading"><span>教育学习</span> <span class="arrow right"></span></p> <!----></section></li></ul> </aside> <div><main class="page"><div class="theme-vdoing-wrapper "><div class="articleInfo-wrap" data-v-5712e8f9><div class="articleInfo" data-v-5712e8f9><ul class="breadcrumbs" data-v-5712e8f9><li data-v-5712e8f9><a href="/brennan-wu-blog/" title="首页" class="iconfont icon-home router-link-active" data-v-5712e8f9></a></li> <li data-v-5712e8f9><a href="/brennan-wu-blog/read/#读书笔记" data-v-5712e8f9>读书笔记</a></li><li data-v-5712e8f9><a href="/brennan-wu-blog/read/#专业技术" data-v-5712e8f9>专业技术</a></li></ul> <div class="info" data-v-5712e8f9><div title="作者" class="author iconfont icon-geren" data-v-5712e8f9><a href="https://github.com/wyd112821" target="_blank" title="作者" class="beLink" data-v-5712e8f9>Brennan Wu</a></div> <div title="创建时间" class="date iconfont icon-rili" data-v-5712e8f9><a href="javascript:;" data-v-5712e8f9>2022-09-18</a></div> <!----></div></div></div> <!----> <div class="content-wrapper"><div class="right-menu-wrapper"><div class="right-menu-margin"><div class="right-menu-title">目录</div> <div class="right-menu-content"></div></div></div> <h1><img src="">《技术领导力：程序员如何才能带团队》读书笔记<!----></h1> <!----> <div class="theme-vdoing-content content__default"><h1 id="《技术领导力-程序员如何才能带团队》读书笔记"><a href="#《技术领导力-程序员如何才能带团队》读书笔记" class="header-anchor">#</a> 《技术领导力：程序员如何才能带团队》读书笔记</h1> <p><img src="https://cdn.staticaly.com/gh/wyd112821/Blogger@master/static_files/img/v2-934982f6464a93d033e7f2ace82aa405.2ebmzwlwodes.webp" alt="v2-934982f6464a93d033e7f2ace82aa405"></p> <h2 id="第1章-技术管理工作"><a href="#第1章-技术管理工作" class="header-anchor">#</a> 第1章 技术管理工作</h2> <h3 id="_1-1技术管理"><a href="#_1-1技术管理" class="header-anchor">#</a> 1.1技术管理</h3> <p>个人的高效能不可怕，团队的高效能才可怕，当团队中每个人的潜力都被发掘出来，能力的集合才是巨大的，才能所向披靡。</p> <p>我们每位技术团队管理者，也正在像书一样被摆放在被管理者面前，如果别人懒得翻你，就证明你不能给予他们指导，他们没有归属感，最终都会匆匆离职。</p> <p>技术团队管理者需要具备的能力</p> <ul><li>深入理解一门或多门编程语言</li> <li>深入理解多种流行的框架</li> <li>系统架构能力强，拥有复杂系统的设计经验</li> <li>积极跟随开源社区</li> <li>积极了解业界技术发展</li> <li>沟通能力强、情商高</li> <li>有产品意识，不是技术迷</li> <li>会带人，服从领导，责任心强</li> <li>会写专利</li></ul> <h3 id="_1-2-技术团队领导者"><a href="#_1-2-技术团队领导者" class="header-anchor">#</a> 1.2 技术团队领导者</h3> <h4 id="工作职责定位"><a href="#工作职责定位" class="header-anchor">#</a> 工作职责定位</h4> <p>只有成为“技术的业务派，业务的技术派”，才能让技术引领业务，并创造价值。这其实也是技术管理者成熟的标志。</p> <p>一位管理者最重要的是给团队指明方向，包括技术方向和业务方向，还有个人成长方向。与下属相比，领导者的优势不只在于他的专业能力，还在于他的眼光和胸怀。既然选择做技术管理，你就要有成就他人的心胸，同时还要有超出一般人的眼界，能够给予团队正确的方向。同时，要保持对技术的兴趣，多关注新技术的发展，否则你很难在重大的技术决策上做出正确的决定。</p> <h4 id="工作品质定位"><a href="#工作品质定位" class="header-anchor">#</a> 工作品质定位</h4> <ul><li><p><strong>成熟</strong>——重视诺言、不夸夸其谈、有学识而含蓄内敛、心胸宽广、不以自我为中心、勇于承认错误、意志坚定</p></li> <li><p><strong>勇敢</strong>——作为团队负责人，我们应该有硬汉本色，不能惧怕外在的威胁。团队成员都在看着你，你决不能懦弱，要勇敢。</p></li> <li><p><strong>热爱技术</strong>——我们输出或者呈现给别人的技术能力，需要且必须是公司内部的技术权威之一；但有一点需要注意，只有做好当前的事情，你才有资格谈技术理想。</p></li> <li><p><strong>勤奋</strong>——作为一名技术团队管理者，你要做的是比别人更早接触新技术，更深入地理解系统架构，全面提高管理团队所需的方方面面的能力，而所有这些都需要勤奋。</p></li> <li><p><strong>脚踏实地</strong>——很多技术团队管理者，无论是初次担任还是资深人士，都会出现看不清自己的情况，即说白了容易自大。人只要开始自大，就容易犯错误：技术、产品上容易定位失误，管理上容易霸道待人。</p></li> <li><p><strong>逻辑能力</strong>——程序员的工具是编程语言，日常活动和主要工作包括设计（Design）、建模（Model）、编码（Code）、调试（DeBug）、重构（Refactor）、沟通（Communicate）、学习（Learn）和思考（Think），所有这些工作对一个人的逻辑能力要求都很高。一个人的逻辑能力属于软实力，它是决定你是否可以承担团队领导职责的关键因素。</p></li> <li><p><strong>公平、透明</strong>——无论是绩效考核，还是职位升迁，亦或是问题处理，都不应该由少数几个领导通过闭门会议的形式完成，而应该是通过制定逻辑严谨的规章制度，通过类似任职资格考核的方式完成初步考察，然后通过事情责任制方式明确个人的成绩、责任，最后通过有员工代表、相应部门代表参与的会议讨论决定，这样可以让整个团队朝着健康的方向发展，而不会让一部分人感觉被边缘化，从而滋生小团体。</p></li> <li><p><strong>一线作战精神</strong>——既然承担了团队负责人的实际工作，那么就应该定期召开例会，不断地抽时间和大家一起讨论架构、业务流程、技术难点、技术方向等，要以身作则，这是你的职责。</p></li> <li><p><strong>决策能力</strong></p> <ul><li><strong>开放的提炼能力</strong>——以开放的态度，准确和迅速地提炼出解决问题的各种方案的能力。</li> <li><strong>准确的预测能力</strong>——预测是决策的基础，决策是预测的延续，预测的目的是为企业的决策提供准确的资料、信息和数据，在正确预测的基础上，选择符合企业发展的满意方案。</li> <li><strong>准确的决断能力</strong>——从众多的决策方案中选取满意方案的能力，以及危机时刻或紧要关头有当机立断的决断能力。</li> <li><strong>如何培养决策能力</strong> <ul><li>克服从众心理</li> <li>增强自信心</li> <li>决策勿求十全十美，注意把握大局。</li></ul></li></ul></li> <li><p><strong>开放姿态</strong>——我们需要倡导“开放、共享、追求极致”的团队文化。人才是我们最大的财富，所以要建设以人为本的团队文化，创造出沟通顺畅、敢于挑战、喜欢创新的团队氛围。</p></li> <li><p><strong>为人处世</strong>——我们需要无比庄敬自强，公平待人，不可欺负弱势的人，也不可以做损及他人或自己的事。同时，我们需要一个谦卑的团队负责人，谦卑的人不会固执己见，而是会虚怀若谷地聆听他人的言论。</p></li> <li><p><strong>真诚</strong>——在工作时，我们和团队成员是上下级关系，也是合作关系，共同运营着这个团队，我们需要真诚待人，有什么问题可以在会议上或者一对一谈话时指出，说出自己对他工作的看法。生活中，我们是朋友，有什么事情都可以一起讨论，想办法解决。你若待人真诚，别人也会用心对你。</p></li> <li><p><strong>宽容</strong>——我常说的是，这个人如果自身能力较弱，不愿承认，那就是作死。如果自身能力很强，也很积极做事，这个时候我们应该多放权，让他自己思考，他也会乐于如此。如果自身能力不强，但是他对自身弱点有认识，工作态度很好，这个时候犯错了，我们不能过度责骂，应该宽容对待，先问清楚原因，然后和他一起分析过程，帮助他成长，只要他成长了，我们的团队整体也会受益。</p></li> <li><p><strong>仔细</strong>——抓细节是作为一名技术团队管理者必须做到的。所谓的管理浮于表面，一般都是说管理者不关注细节，例如不参与设计、不参与代码审核，而只是高喊要注意开发设计、注意开发质量，这样的领导对于技术团队来说，尤其是一线技术团队经理来说，是不合格的，也是不能服众的。</p></li> <li><p><strong>终身学习</strong>——当你在时间的长河中坚持不懈地学习，你的知识将会在复利的作用下持续地累积和增长，最终的收获和回报会远远超出你的想象，而实现终生学习的最佳途径，就是阅读大量优秀的书籍。</p></li> <li><p><strong>时间管理</strong>——作为一名管理者，很多时候自己所能支配的时间大多有限，只有学会集中精力、善用碎片时间，才能让工作效率更高。如果管理者在多个行业或项目中拥有较多的资源，那么需要自己设定优先次序，而且遵循要事第一的原则，坚守其设定的优先次序。战线如果太长，势必造成精力无法集中，反而会影响一些原本优先级较高的项目的执行。</p></li> <li><p><strong>以人为本</strong>作为管理者，你的工作中很重要的一项；绝对不可忽视你团队的人，并始终要坚持以人为本。</p></li> <li><p><strong>保持身体健康</strong>钱能买到一切有价的东西，独独换不回健康，也唯有生命才是无价的。</p></li></ul> <h3 id="_1-3-带领技术团队心得"><a href="#_1-3-带领技术团队心得" class="header-anchor">#</a> 1.3 带领技术团队心得</h3> <h4 id="自主循环"><a href="#自主循环" class="header-anchor">#</a> 自主循环</h4> <p>我们带领一支团队，可能是1、2个人，也可能是几十个人，甚至上百人，我们不可能做到事无巨细、一一谈话，很多时候需要分小组讨论，也要依赖于个人自主工作态度，这就是我们所说的自主循环。</p> <h4 id="技术人员心态成长四阶段"><a href="#技术人员心态成长四阶段" class="header-anchor">#</a> 技术人员心态成长四阶段</h4> <ul><li><strong>感知阶段</strong>——这个阶段的人还没有完全成熟，也许将来他们会离开技术领域，也许他们会沉淀下来，专心搞技术，这都无所谓，关键是要想清楚，多和前辈聊聊，交换思想，知道怎么做才能达到自己的目标，并付诸实施，如果你觉得自己做不到，那说明你选错岗位了。</li> <li><strong>深入阶段</strong>——对于这类人的指导，应该从实践着手，给他们一些独立思考的机会，给予他们实际的指导，就事论事，就架构论架构，就代码论代码。</li> <li><strong>突破阶段</strong>——需要让他们有完整的独立思考机会，安排一些从头开始的工作给他们，然后积极地与他们进行讨论，适度授权，让他们一边自我实现，一边听到你的看法。</li> <li><strong>创新阶段</strong>——给予掌声、认真倾听、给予意见，最好你能一同参与创新活动，这样你们才能一起进步、创新。</li></ul> <h4 id="找到属于自己的圈子"><a href="#找到属于自己的圈子" class="header-anchor">#</a> 找到属于自己的圈子</h4> <p>在成为管理者，特别是成为具有一定管理经验的技术管理者之后，我们需要能够发现并组织一个属于自己知识交流的圈子，这个圈子需要定期碰面，讨论各自正在从事的工作以及软件开发中遇到的具有挑战性的问题。这种方式会帮助彼此从对方那里获得帮助，时不时还能共同总结出一条至理名言或经验法则，然后各自可以把这些至理名言和经验法则整合到管理方法中，并与团队分享。</p> <h4 id="何时成为技术管理者"><a href="#何时成为技术管理者" class="header-anchor">#</a> 何时成为技术管理者</h4> <p>这没有恒定的标准，但是我的建议是，先打好技术基础。当你觉得每天只有50%时间可以做技术的时候，但你还是能够紧跟技术，甚至比你的大多数下属都了解细节的时候，你就可以尝试给自己加上技术管理的工作量了。</p> <h3 id="_1-4-个人职业发展"><a href="#_1-4-个人职业发展" class="header-anchor">#</a> 1.4 个人职业发展</h3> <h4 id="对于职业的选择"><a href="#对于职业的选择" class="header-anchor">#</a> 对于职业的选择</h4> <p>从技术转管理本身就是一个很大的转变，一旦跳进去，就很难爬出来了。我认为最大的差异就是，技术面对的是系统性问题，需要的是逻辑思维能力，是智商，而管理需要面对的很多是非逻辑思维能力，是情商。系统问题需要智商，而人是活的，你要理解人，就需要情商，情商是什么？我个人理解，情商就是如何站在别人的角度看问题。</p> <h4 id="工程师的等级"><a href="#工程师的等级" class="header-anchor">#</a> 工程师的等级</h4> <ul><li>第五等工程师，能够独立设计和实现一项功能的人。这是对工程师的基本要求。</li> <li>第四等工程师需要有点产品头脑，也就是说他们在做一件事之前，要知道所做出来的东西是否有用、易用，是否便于维护，是否性能稳定，等等。除了要具备产品设计方面的基本知识，还要具有一定的领导才能，能从头到尾负责一个产品的生命周期。</li> <li>第三等工程师，可以做出行业里最好的产品。他们与第四等工程师有着质的差别，这不仅反映在技术水平、对市场的了解、对用户新的了解以及组织能力等诸方面，而且也反映在悟性的差异上。</li> <li>第二等工程师是那些可以给世界带来惊喜的人，他们在其工作的原创性以及对世界的影响力上和后面三等有巨大差别。</li> <li>第一等工程师是开创一个全新行业的人，这些工程师不仅在技术和产品等各个方面与第二等工程师有了质的差别，而且在经验和管理上也是好手，他们通常也是企业家，并通过自己的产品改变了世界。</li></ul> <h4 id="不要计较当下职位"><a href="#不要计较当下职位" class="header-anchor">#</a> 不要计较当下职位</h4> <p>在企业里面成功，不可否认仍依仗两个方面：要么你聪明，会交际，懂政治，被人认可；要么你做出成绩，贡献巨大，被认可。我觉得，技术人员还是选后面一条比较合适，持续地积累自己的技术，最终你的成长会由量变达到质变。</p> <h4 id="坚持做正确的技术管理"><a href="#坚持做正确的技术管理" class="header-anchor">#</a> 坚持做正确的技术管理</h4> <p>不断地调整自己的工作方式，不断地加强自己各方面的能力，特别是改正自己的弱点，这些才是你应该去关注和为之努力的。</p> <h4 id="抛弃通道思维-建立雷达视角"><a href="#抛弃通道思维-建立雷达视角" class="header-anchor">#</a> 抛弃通道思维，建立雷达视角</h4> <p>以技术管理者为例，他除了技术能力通道以外，还需要走管理通道。因为没有管理，整个团队会乱，技术与管理结合的方法论掌握不好，整个团队的绩效输出都会差，你别指望纯技术通道的人能够输出业务部门能够理解的产物。也就是说，需要能够抛弃单一通道的约束，尽量做到全面的能力建设，即抛弃通道思维。</p> <p>我们需要坚持学习，不然随着年龄的增加，你的优势会逐渐消失。抛弃通道思维，建立起自己学习新知识的雷达视角，建立起自己的朋友圈，扩大雷达视角范围，对你一定会有用的。</p> <h4 id="职业生涯的收入趋势"><a href="#职业生涯的收入趋势" class="header-anchor">#</a> 职业生涯的收入趋势</h4> <p>从业者整个职业生涯一直在不断地学习、在不断地增强自己的综合能力、不断地自我积极调整以适应企业需求。这类人会很成功，能够保持大体上的收入不断增长，一直到退休功成身退。能够真正做到这样的技术人员很少，大家共勉吧。</p> <h2 id="第2章-团队管理、人员管理"><a href="#第2章-团队管理、人员管理" class="header-anchor">#</a> 第2章 团队管理、人员管理</h2> <h3 id="_2-1-管理基础"><a href="#_2-1-管理基础" class="header-anchor">#</a> 2.1 管理基础</h3> <h4 id="什么是管理"><a href="#什么是管理" class="header-anchor">#</a> 什么是管理</h4> <p>观察、假设、校验，是一切科学实践的基础，管理活动也是类似。</p> <p>通过不断地刻意训练，慢慢积累自己的管理经验，再想着怎么去拿捏平衡，完成类似艺术形态的进化。</p> <h4 id="团队成员品质"><a href="#团队成员品质" class="header-anchor">#</a> 团队成员品质</h4> <p>一支整体作战能力较强的开发团队，它雇佣的员工需要具备以下几点素质：</p> <ul><li><strong>职业素养</strong>——不要贪图小利，一个人的职业素养非常重要，让别人觉得你的职业素养有问题，你的职业生涯也会很危险。</li> <li><strong>做事专注</strong>——一名真正的技术牛人，他在做事的时候绝对是全神贯注的，否则他不可能在短时间内读懂别人的代码、找到问题原因、完成框架设计，这是技术专家的必备能力。</li> <li><strong>乐于挑战</strong>——在工作中你一定会遇到各种各样的挑战，你所需要做的是积极地迎接、应对这些挑战，而不是每次都退缩，越退缩就越容易失去机会，失去让自己过上自己喜欢的生活的机会。</li> <li><strong>永不气馁</strong>——遇到困难不要轻易放弃，我们现在遭遇的失败，恰恰是我们以后取得成功的原因。</li> <li><strong>承认错误</strong>——敢于承认错误，并积极地弥补错误所造成的损失，是一种非常可贵的精神，值得我们大力称赞。</li></ul> <h3 id="_2-2-组建团队"><a href="#_2-2-组建团队" class="header-anchor">#</a> 2.2 组建团队</h3> <h4 id="招聘策略"><a href="#招聘策略" class="header-anchor">#</a> 招聘策略</h4> <ul><li><strong>解岗位需求</strong>——我们需要明确知道自己需要什么样的程序员，需要分析自己所提供的岗位，即便都是合格的程序员，也需要根据我们的实际需求确定最适合的那一位，也就是说，明确我们当前是需要开发经验，还是需要对技术有钻研热情的人。</li> <li><strong>编写职位描述</strong>——建议不要只写一份职位描述，而是要多写几组，以体现对不同工作的能力要求。根据过往经验，多写几组职位描述可以更容易让应聘者看到职业发展和晋升机会，不仅有利于HR招聘，也能帮助应聘者定位。</li> <li><strong>STAR面试法</strong>——在招聘面试中，仅通过应聘者的简历无法全面了解应聘者的知识、经验、技能、工作风格、性格特点等，而使用STAR技巧则可以对应聘者做出全面而客观的评价。</li> <li><strong>招聘文化</strong>——好的招聘流程可以促成好的工程团队文化，必须做到快速回应、测试驱动和积极沟通</li></ul> <h4 id="面试技巧"><a href="#面试技巧" class="header-anchor">#</a> 面试技巧</h4> <ul><li><strong>学历</strong>——对于中小型公司来说，不要太在意学历；对于工作很多年的人来说，他的实际工作经历远比大学学历重要得多。</li> <li><strong>面试题</strong>——面试过程体现了一家公司的技术能力、思维和管理能力，绝不可以轻率应付，你代表着公司，而不仅仅是你个人，如果你不够资格，或者根本不想做好，那请你让开位子，请合格的人来坐。</li> <li><strong>逻辑思维观察</strong>——我一般会让面试者对我口述的场景和需要做的事情进行快速地归纳总结，从他开始阅读或者倾听我的话开始计时，直到他用最简洁的语句描述出事情的背景及我希望他做的事情为止。</li> <li><strong>面试官形象</strong>——公司派我们出去面试，代表的是公司的形象，这自然不用多说，另外需要注意的是，你面试的人是在整个公司使用的，不是只给自己使用的，所以需要对技术严格把关，加强责任心，只录取技术能力过关的、性格适合做技术工作的人，不要受自身情绪影响，导致录取不合适的人。</li></ul> <h4 id="性格分析"><a href="#性格分析" class="header-anchor">#</a> 性格分析</h4> <p>九型人格是一种深层次了解人的方法和学问，它按照人们的思维、情绪和行为，将人分为九种：完美主义者（完美型）、给予者（助人型）、实干者（成就型）、悲情浪漫者（自我型）、观察者（理智型）、怀疑者（忠诚型）、享乐主义者（活跃型）、保护者（平和型）、调停者（领袖型）。九型人格最卓越之处在于能穿透人们表面的喜怒哀乐，进入人心最隐秘之处，发现人最真实、最根本的需求和渴望（这个对于工作来说很重要）。九型人格能够帮助我们洞察人心，从而用有效地方式应对他人，最终提升我们人生的幸福感和成功率。</p> <p>通过让应聘者做测试题目，你可以分析出他的内在性格，从而帮助你决定是否接纳他成为团队成员。</p> <h4 id="人员分类"><a href="#人员分类" class="header-anchor">#</a> 人员分类</h4> <ul><li><strong>“独狼”和“农民”</strong>——从团队角度来看，我们更加希望软件开发像种地一样。农民会有条不紊地先去了解地形、研究土地的化学成分，然后种植、浇水、除草，最终收获粮食。可靠、可扩展、可维护的软件也都是这样有条不紊地开发出来的。</li> <li><strong>“英雄”</strong>——这一类人指的是勇于承担需要付出极大努力才能完成的任务，并最终取得成功的人。作为技术团队管理者，你也需要有一定的技术功底，能够让“英雄”觉得可以从你这里学到一些知识，这样才能合作愉快。最后，需要对“英雄”的薪资、福利有所倾斜，并且多和他们沟通，让他们自己选择技术方向，为他们指明职业发展方向，并把他们放入关键项目里。</li> <li><strong>内向的人</strong>——在会议上让他们发言时，当他们分享自己的意见或见解时，都要给予正面的支持，这样可以逐渐帮助他们建立自信，让他们感觉自己对于团队是有贡献的。找机会跟他们交谈，当面认可他们的贡献。与他们的交流要单独进行，通过一些小事情与他们建立特殊的联系，例如分享工作经验、交流教育孩子心得等。总之，要想方设法与他们建立更紧密的联系。</li> <li><strong>带有明显负能量的人</strong>——尽量避免团队里存在充满负能量的人，他们可能会挑拨离间或发泄不满情绪来影响整个开发团队，并且对组织造成严重破坏。</li> <li><strong>离奇之人与离奇之事</strong>——对于技术团队来说，我们需要的是刻苦的工程师，需要的是能够解决问题的工程师，而不是搞办公室政治的高手，或者腹黑的工程师。早点让他们走，无论他们的水平有多高，都不要犹豫，也不要期望自己能够改变他们什么。让这些人尽快远离团队，这样整个团队都会轻松很多。</li></ul> <h4 id="新员工入职"><a href="#新员工入职" class="header-anchor">#</a> 新员工入职</h4> <p>这是一个向新员工表达你对他们非常看重，且你的团队管理与运行状况也十分良好的机会。团队管理者一般都要负责为新员工寻找工作定位。</p> <p>新员工流失的原因大致有三类：</p> <ol><li><strong>没有对新员工进行明确区分</strong>——需要按照工作年限、岗位级别等区分社招员工的培训内容和方式，对不同的人做正确的培训，会对后续的工作帮助更大。</li> <li><strong>忽略新员工直属主管的重要作用</strong>——人才成长是一个长期培训的过程，任何企业都无法通过新员工培训就帮助其快速成长，还要依靠新员工主管后期对新员工进行更多的培训才能达成</li> <li><strong>培训方式缺失</strong>——无论是选择内部培训还是外部培训，重点要考虑培训的对象和背景。</li></ol> <h3 id="_2-3-管理团队"><a href="#_2-3-管理团队" class="header-anchor">#</a> 2.3 管理团队</h3> <p>管理的最终目标是：“不要让你的下属陷入困境，不要让你的同事陷入困境，尤其是在任何情况下，都不要让你的上级陷入困境”。</p> <h4 id="向下管理"><a href="#向下管理" class="header-anchor">#</a> 向下管理</h4> <ul><li><strong>技术尊重</strong>——成功地管理程序员最重要、最关键的因素，是在技术层面得到他们的尊重。如果没有技术尊重，那么你的每一个具体想法，都可能会遇到主动或者被动的阻碍。</li> <li><strong>进度管理</strong>——每天花时间和团队成员过一遍当前进展。这种方式可以确保自己不仅仅依赖于状态报告、项目时间表，这种方式也可以让你能够接触到说真话的员工，他们会告诉你哪些地方做得不够好，并且会主动请求团队管理者帮助，而不需要团队管理者来催促他们。</li> <li><strong>效率管理</strong>——提高效率，最重要的是先确保做正确的事，再把正确的事做对；高效与工具化、自动化程度强相关，因为自动化具有规范、一致、高速、闭环反馈等特性，而且不会因为疲劳而下降；高效的组织，每个人都会主动优化流程，并且持续改进。</li> <li><strong>引导工作</strong>——对于一个团队管理者来说，要想最大化地利用自己的时间和技能，就要引导程序员自己做出正确的决定，而不应该自己就把决定做了。这样做可以帮助下属员工培养技术、积累经验、建立自信，还能获得具体执行决定的员工的认同。</li> <li><strong>保护成员</strong>——我们要学会保护团队成员，让他们免受组织中的各种问题、争议和“机会”的干扰。</li> <li><strong>评估和改进绩效</strong>——为每一个人设定工作目标并规定完成的时间，接着定期审查这些目标的进度和实现方式。</li> <li><strong>裁员</strong>——表现差的人可能会影响项目的进度，从而对项目中的每个人都产生不利影响。因此无论如何，这种情况必须尽快解决。</li> <li><strong>主动沟通</strong>——承担并顺利地完成与员工的主动沟通，这是你的职责，千万不要轻视沟通能力，这一能力对你的晋升起决定性作用。</li> <li><strong>下放权力</strong>——管理者需要为成果而工作，以结果为导向。一位卓越的管理者不应该在工作一开始就身先士卒地从事具体的工作，更不应该把精力放在研究技术实现的细节上，而是首先问问自己：“客户期望我做出什么样的成果？”然后再对整个项目进行规划。</li> <li><strong>激励员工</strong>——我们只有更好地了解员工的工作动机，才能更好地激励他们。激励因素包括成就、认可、工作本身、责任、发展，只有当这些都得到实现和满足时，人们才能得到真正的激励。</li></ul> <h4 id="向上管理"><a href="#向上管理" class="header-anchor">#</a> 向上管理</h4> <p>指的是如何有效管理你的老板以及你要汇报的那些人。另外，你还需要弄清楚如何汇报、如何沟通，以及要采取什么样的行动，才能让你的老板认为你是一个高效而成功的员工。</p> <ul><li><strong>了解老板</strong>——你需要清醒地评估如何高效地与老板进行沟通。即使是你问他们想要什么，也可能会因为沟通不当，传达给他们错误的信息，或者详细程度不恰当，而他们的自我评估可能也会弄错他们真正想要的东西。所以双方应当一致迭代优化沟通，调整需要沟通的度量。</li> <li><strong>准备讨论内容</strong>——不要把每一个问题都带到你老板那里寻求解决方案。最好是拿着几套潜在的解决方案和问题一起交给他。</li> <li><strong>主动承担</strong>——学会给人惊喜与欢乐。了解哪些事情会让你老板时刻关注，并找到办法超水平完成任务，最好是超过他的预期。有时候其实并不是做得越多越好，而是处理较多复杂问题。</li></ul> <p>向上管理本身也有直接的回报：当你为更多的交流做出努力时，会潜在加固和上层领导的关系。可能其中一位领导，会成为你的好友，并在你今后的职业生涯中一直支持你。</p> <h4 id="对外管理"><a href="#对外管理" class="header-anchor">#</a> 对外管理</h4> <ul><li><strong>与部门内的人合作</strong>——这种合作可以表现为互相帮助、对遇到的问题互相提供超常规的支持、共享资源和培训，并相互守望。</li> <li><strong>了解其他部门</strong>——建立起彼此之间的跨部门纽带关系是很有必要的，不仅能帮助你自己，也是促进不同部门团队之间双向协作的重要途径。</li> <li><strong>平级的人相处</strong>——首先要自我检查，确保不是自身的问题，然后是沟通，保持高效、简单的沟通，这样可以帮助你至少说出自己的困惑，最后是放松自我，不要被不值得的事情或人所烦恼，过好自己的每一天，全力做好自己的工作，不断提升自我价值。</li></ul> <h4 id="自我管理"><a href="#自我管理" class="header-anchor">#</a> 自我管理</h4> <p>首先需要实事求是地评估自己的习惯、实践和行为，然后找出你想要改变的方面，最后实施你的改善计划。</p> <h3 id="_2-4-影响团队因素"><a href="#_2-4-影响团队因素" class="header-anchor">#</a> 2.4 影响团队因素</h3> <h4 id="不懂技术的技术领导"><a href="#不懂技术的技术领导" class="header-anchor">#</a> 不懂技术的技术领导</h4> <p>团队领导可以不是对口的专业出身，但是他必须对技术有热情，必须有开发经历，需要对技术有敬畏之心。总结为两点：</p> <ul><li>基础知识和理论知识非常重要，多多使用已有的且成熟的方案是关键。</li> <li>对技术要有一颗严谨和敬畏的心，想清楚了再干，坚持高标准，很多事情都急不来。</li></ul> <h4 id="薪资管理"><a href="#薪资管理" class="header-anchor">#</a> 薪资管理</h4> <p>对于薪资，一个基本的观点就是：<strong>公平、公正</strong>。我们应该注意以下几点：</p> <ul><li>按照能力和他的付出进行衡量，不要把个人情感混淆其中。</li> <li>制定标准化的考核规则，输出能够让人信服的流程和细则。</li> <li>薪资的组成结构最好能够多元化，这样可以让员工在每一项奖金中感受自己的付出和回报。</li> <li>薪资真的是第一要务，一定要把握标准，做到公平、公正，不然你的团队会垮的。</li></ul> <h4 id="上升通道"><a href="#上升通道" class="header-anchor">#</a> 上升通道</h4> <p>作为技术团队管理者，应该多与每一位下属沟通，抽出时间来了解他们对于未来的期望，帮助他们逐渐设计符合他们想法的上升通道。当然，你给予他们机会，最终需要他们能够承担这个机会，承担机会意味着付出，如果这个人不愿意付出，只是口头不断表达自己的想法，那么所有的上升通道都不会向他敞开。</p> <h4 id="大规模变革"><a href="#大规模变革" class="header-anchor">#</a> 大规模变革</h4> <p>一定要慎重执行大规模变革，无论是组织架构，还是人员任命，因为所有的改变，都会在人的内心引起权力欲望和恐惧。多做核心人物的思想沟通工作，不要由闭门小团体会议决定所有的改变方案，这样会让核心技术人员感觉到被边缘化、被决定命运。</p> <h4 id="一言堂"><a href="#一言堂" class="header-anchor">#</a> 一言堂</h4> <p>需要针对团队管理者制定多方面考核机制，要有自下向上的反馈渠道，避免出现有违公司政策、违反劳动法的事情出现。作为一名团队管理者，有一点是需要做到：“不要作恶！”</p> <h4 id="频繁开会"><a href="#频繁开会" class="header-anchor">#</a> 频繁开会</h4> <p>针对于不同的组织和项目，能尽快找出相应的沟通节点并能有效地减少这些沟通节点，是一个项目和部门领导需要经常思考的问题。</p> <h4 id="老员工的管理"><a href="#老员工的管理" class="header-anchor">#</a> 老员工的管理</h4> <p>如果人的成长速度慢于公司，那么公司要做的事和人能做的事之间就会产生一个缺口。这个缺口需要管理者去填补，可能需要加人或者其他人去做。但在填补这个缺口之前需要和老员工进行深入的沟通。</p> <p>在请有问题的人离开时，之前的承诺全部要兑现，这是一个管理者的道德。</p> <h4 id="工作时间"><a href="#工作时间" class="header-anchor">#</a> 工作时间</h4> <p>谈到工作时间，其实大家想表达的是时间自由，相比较时间自由而言，当代社会更多的是应该看是否能力自由。</p> <p>真正应该关注的是工作能力是否自由，如果你能力很强，又很善于掌握新的技能，那你完全可以自己掌控自己的时间，可以自己创业，或者去那些愿意给你时间自由的公司，一切事在人为，关键还是自身。</p> <p>针对程序员最好采用弹性工作制，且每天必须有大于4个小时的时间让大家聚在一起，这样才能够完成需求、设计等评审流程，才能对具体的系统架构、代码问题进行讨论以及与其他职能部门的业务沟通。</p> <h4 id="缺乏愿景"><a href="#缺乏愿景" class="header-anchor">#</a> 缺乏愿景</h4> <p>就是要让一名软件工程师对这家公司有归属感和对未来的期望，这些都是要能够落地的。</p> <p>对一名软件工程师，你最好能够告诉他，你对公司很重要，但关键要说清楚为什么重要，特别需要让他们体会到他们的技术能够不断提高的愿景。</p> <p>大公司有大公司的愿景，小公司有小公司的愿景，我们技术团队和个人应该也有自己的愿景</p> <h3 id="_2-5-其他相关知识"><a href="#_2-5-其他相关知识" class="header-anchor">#</a> 2.5 其他相关知识</h3> <h4 id="理解程序员工作"><a href="#理解程序员工作" class="header-anchor">#</a> 理解程序员工作</h4> <p>技术团队管理者必须培养软件开发文化，而文化又是建立在可靠的开发实践基础上的，否则程序设计项目就可能失败。</p> <p>成功管理程序员的关键是要认识到他们是独立的个体。程序员之间的差异很大，你必须努力地让每个人的长处都得到发挥，同时尽力提高或者至少抵消每个人的短板，这也是对技术管理者的要求。</p> <p>需要一类既能理解程序员的工作方式，又能理解工作本身的技术管理者，他们不仅能有效地激励程序员超常发挥，而且能按时交付结果。</p> <h4 id="杰出的程序员"><a href="#杰出的程序员" class="header-anchor">#</a> 杰出的程序员</h4> <p>杰出的程序员是大师级的人物，做事有条不紊、遵守纪律，能够凭借直觉把代码和程序组织好，能够约束自己总是在编写代码之前进行设计，能够在最少的时间内编写出清晰、简洁、实用、高质量的代码并获得预期的结果。</p> <h4 id="扁平化管理"><a href="#扁平化管理" class="header-anchor">#</a> 扁平化管理</h4> <p>扁平化管理更容易让能干的人冒出来。理论上来说，通过减少管理层次、压缩职能部门和机构、裁减人员，使企业的决策层和操作层之间的中间管理层级尽可能减少，以便使企业快速地将决策权延至企业生产、营销的最前线，从而为提高企业效率建立富有弹性的新型管理模式。</p> <p>知识型员工的一个鲜明特点就是，对专业的忠诚大于对所服务企业的忠诚，选择企业的目的是致力于寻求能够实现自身专业成就最大化的成长平台。</p> <h4 id="团建活动的技巧"><a href="#团建活动的技巧" class="header-anchor">#</a> 团建活动的技巧</h4> <p>倾向于户外活动，最好是有一定强度并过夜的活动，当然最好能够找专业的户外拓展公司来协助，效果会更好。在荒无人烟的野外，通过刻意划分的小组、强制的行为约束、集体的协作，共同挑战艰苦的旅程，在别无选择和共同的困难面前，人和人的心会迅速打开和贴近，自觉地相互帮助共同完成目标，再通过晚上的喝酒助兴进一步加强和巩固团队关系。</p> <h2 id="第3章-产品开发过程管理"><a href="#第3章-产品开发过程管理" class="header-anchor">#</a> 第3章 产品开发过程管理</h2> <h3 id="_3-1-开发经理介绍"><a href="#_3-1-开发经理介绍" class="header-anchor">#</a> 3.1 开发经理介绍</h3> <h4 id="开发经理职务描述"><a href="#开发经理职务描述" class="header-anchor">#</a> 开发经理职务描述</h4> <p>开发经理是公司委派的负责实现产品开发目标的个人，是公司授权的产品开发负责人，是产品开发的直接组织者和领导者。</p> <p>开发经理的职责：</p> <ul><li>对产品开发全过程进行组织和管理，按预期交付产品开发的成果；</li> <li>管理产品开发团队，为成员提供技术和业务上的支撑，使之高效而愉快地工作，并获得最满意的工作体验；</li> <li>管理对外关系，以取得外部对交付成果及过程的最满意评价。</li></ul> <h4 id="开发经理的主要任务"><a href="#开发经理的主要任务" class="header-anchor">#</a> 开发经理的主要任务</h4> <ul><li><strong>与产品经理交流</strong>——开发经理需要近距离地了解需求、资源等约束，这样制定的项目实施方案才会切实可行。与产品经理交流不仅有助于开发经理深入了解客户需求，也可以帮助产品经理了解开发经理的能力。</li> <li><strong>负责产品开发交付</strong>——开发经理不仅要制定思路清晰、考虑周密的计划，还要调整资源、委派任务，推进计划的执行。执行过程中，还要及时处理出现的问题，定期向相关人员汇报进展，保证在规定的时间和预算内交付项目进展。</li> <li><strong>完成产品开发收尾</strong>——完成交付成果之后，要将成果移交相关部门，确保相关部门可以稳定地使用系统。</li> <li><strong>管理干系人的关系</strong>——开发经理作为各方的桥梁和纽带，要随时处理各方信息，保持密切沟通，解决矛盾冲突，只有这样才能让客户满意。</li> <li><strong>管理项目团队</strong>——开发经理需要花费很大的精力寻找合适的资源，优化资源配置，建立合理的组织结构，确定清晰的职责分工。项目过程中还需要通过各种措施进行团队建设，打造高效团队。</li></ul> <p>从这些工作任务的性质来看，开发经理是项目的推动者、技术的输出者，也是关系的协调者。总的来说，开发经理往往是决定一个项目成败的关键人物，要求其职业素养高、技术能力强、综合能力强、职责范围广。</p> <h4 id="开发经理素质"><a href="#开发经理素质" class="header-anchor">#</a> 开发经理素质</h4> <ul><li><strong>领导力</strong>——开发经理需要将一组成员凝聚成一个团队，激发和影响他人为了共同的目标而努力工作。不仅要自己先做到要求别人做到的事，而且要知道“下一步”应该干什么，下一个目标在哪里。</li> <li><strong>责任心</strong>——具有强烈责任心的人，也会非常注重细节，能主动发现问题，会时不时地在脑子中模拟一件事的执行过程，设想各种意外情况，考虑如何应对。这样的人比别人看得远，看得透。</li> <li><strong>积极主动</strong>——积极主动的人最大的特点是不会经常抱怨，因为抱怨本身是没有用的。开发经理必须时刻保持好的心态，如果团队成员始终看到一个信心满满、镇定自若的开发经理，大家也会充满信心。</li> <li><strong>抗压能力</strong>——有抗压能力的人在困难来临的时候仍能镇定自若，仍能冷静思考，即使在无能为力的时候，也能保持“风度”和“幽默感”，从而稳定军心、解决问题。</li></ul> <h3 id="_3-2-产品开发过程管理"><a href="#_3-2-产品开发过程管理" class="header-anchor">#</a> 3.2 产品开发过程管理</h3> <h4 id="项目启动会"><a href="#项目启动会" class="header-anchor">#</a> 项目启动会</h4> <ul><li><strong>目标</strong>——明确该产品开发项目的目标。</li> <li><strong>准备工作</strong>——在项目启动会之前，我们需要和用户沟通并明确用户需求。</li> <li><strong>过程及议题</strong>——
❑ 介绍议程和来宾；
❑ 介绍项目目标、阶段计划、管理方法；
❑ 发布项目的组织结构图；
❑ 确认关键角色及其职责，并作出承诺；
❑ 参会人员针对介绍内容进行提问交流；
❑ 高层领导做项目动员发言，激励和鼓舞士气；
❑ 各个相关部门领导表态支持项目工作。</li> <li><strong>经验和教训</strong>——启动阶段，需要迅速建立组织架构、明确分工，分头工作，然后再着手制定后续详细的项目计划；项目启动会准备阶段，最好请一个有经验的专家一起参与，帮助开发经理落实很多关键环节，也需要组织团队内部进行讨论。</li></ul> <h4 id="用户需求-产品需求"><a href="#用户需求-产品需求" class="header-anchor">#</a> 用户需求&amp;产品需求</h4> <p>用户需求由用户提出，对技术一般不描述，只描述产品目标。</p> <p>产品需求是根据用户需求转化而来的技术实现需求，需要针对用户提出的产品目标进行细分，总结出具体的功能点，再针对每一个功能点细分为各种不同的操作流程，对每一个操作流程进行技术化定义。</p> <p>用户需求和产品需求容易产生差异，出现需求理解不一致的情况。</p> <p>针对这类需求理解不一致的情况，总结如下：</p> <ul><li>开任何会议，一定不要上来就讲解方案，应该先讲解场景；</li> <li>大家一起讨论，研究这个场景背后的需求是不是最佳场景，能不能删除这个场景，或者是否有其他场景可以代替这个场景同时还能满足背后的需求；</li> <li>如果是需求的最佳场景，再开始讨论这个场景下的产品解决方案；</li> <li>这个时候你打开事先设计好的产品原型图、产品流程图、状态图、用例图，你会发现有很多需要修改，修改之后就是大家一起生成的方案。</li></ul> <h4 id="总体设计"><a href="#总体设计" class="header-anchor">#</a> 总体设计</h4> <p>总体设计是整个系统的框架型设计，意义极其重大，一般情况下不能省略，所有的产品开发项目均需要首先进行总体设计。</p> <p>总体设计分为三个阶段：</p> <ul><li>第一阶段：初始设计。在对给定的数据流图进行复审和精化的基础上，将其转化为初始的模块结构图。</li> <li>第二阶段：精化设计。依据模块“高内聚低耦合”的原则，精化初始的模块结构图，并设计其中的全局数据结构和每一模块的接口。</li> <li>第三阶段：设计复审阶段。对前两个阶段得到的高层软件结构进行复审，必要时还可能需要对软件结构做一些精化工作。</li></ul> <h4 id="概要设计"><a href="#概要设计" class="header-anchor">#</a> 概要设计</h4> <p>概要设计的目的是描述系统每个模块的内部设计，对总体设计和详细设计承担起承上启下的作用。</p> <p>概要设计阶段将软件按照一定的原则分解为模块层次，赋予每个模块一定的任务，并确定模块间的调用关系和接口。</p> <h4 id="详细设计"><a href="#详细设计" class="header-anchor">#</a> 详细设计</h4> <p>详细设计阶段就是依据概要设计阶段的分解，设计每个模块内的算法、流程，为每个模块完成的功能进行具体的描述，把功能描述转变为精确的、结构化的过程描述。</p> <h4 id="编写代码"><a href="#编写代码" class="header-anchor">#</a> 编写代码</h4> <p>编码技巧:</p> <ul><li>优先考虑核心模块的压力测试；</li> <li>确保过程可控；</li> <li>预留地方写注释；</li> <li>用人人看得懂的逻辑；</li> <li>不要沉迷于框架；</li> <li>使用熟悉、成熟的技术；</li> <li>细节没优化前，别谈架构；</li> <li>多留日志；</li></ul> <h4 id="代码审核"><a href="#代码审核" class="header-anchor">#</a> 代码审核</h4> <p>在团队中进行代码审查（Code Review）可以提升代码质量，分享项目知识、明确责任，最终构建更好的软件、更好的团队。</p> <p>代码审核内容由如下部分组成：</p> <ul><li>前置条件：代码是否可以正常运行、开发工具或者运行过程当中有没有严重警告灯。</li> <li>代码规范性：主要由注释、排版、命名规则等组成;</li> <li>代码逻辑：包括函数、控制结构、内存管理、类/结构体、其他高级特性、并发处理、设计模式使用、跨平台设计等。</li></ul> <h4 id="单元测试"><a href="#单元测试" class="header-anchor">#</a> 单元测试</h4> <p>单元测试是一种白盒测试，就是必须要对单元的代码细节很清楚才能做的测试。所以，单元测试的编写和执行都是由软件工程师来做的。</p> <h4 id="集成测试"><a href="#集成测试" class="header-anchor">#</a> 集成测试</h4> <p>集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。</p> <p>将经过单元测试的模块组装成完整的程序。工作任务包括制定集成测试策略，确定集成测试步骤，设计集成测试用例，然后逐一添加模块进行测试。集成测试由测试人员负责，应该在概要设计完成后进行设计工作，并在单元测试完成后执行。</p> <h4 id="系统测试"><a href="#系统测试" class="header-anchor">#</a> 系统测试</h4> <p>系统测试阶段包括系统测试方案和用例编写、功能性测试、性能测试、稳定性测试。</p> <h4 id="产品发布"><a href="#产品发布" class="header-anchor">#</a> 产品发布</h4> <p>产品发布前需要通过产品发布说明会的形式，对整个产品开发过程从立项开始回溯过程，总结整个过程中的经验教训。</p> <h4 id="开发过程复盘"><a href="#开发过程复盘" class="header-anchor">#</a> 开发过程复盘</h4> <p>总结项目经验教训的目的在于总结问题、分析原因，避免以后犯同样的错误，而不是追究谁的责任。</p> <h3 id="_3-3-产品开发过程杂谈"><a href="#_3-3-产品开发过程杂谈" class="header-anchor">#</a> 3.3 产品开发过程杂谈</h3> <h4 id="理解业务的重要性"><a href="#理解业务的重要性" class="header-anchor">#</a> 理解业务的重要性</h4> <p>为了能够让业务在软件中很好地运行起来，软件工程师必须理解业务的生命周期、拆分方式，以及业务服务对象的利益所在，即业务问题。</p> <h4 id="应对需求变更"><a href="#应对需求变更" class="header-anchor">#</a> 应对需求变更</h4> <p>在项目中发生需求变更是难免的，我们不能抵制变更，但是一定要用切实有效的办法控制变更。变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。</p> <h4 id="开发进度管理"><a href="#开发进度管理" class="header-anchor">#</a> 开发进度管理</h4> <p>为了有效控制进度，开发经理需要定期召开例会，项目组全体成员都要参加。</p> <p>例会上检查和调整项目计划，关注的问题是：任务完成了吗？没完成的原因是什么？怎么调整？先确认了状态，再讨论该如何调整工作或计划，并一定要落实到具体的行动方案上。</p> <h4 id="评审的重要性"><a href="#评审的重要性" class="header-anchor">#</a> 评审的重要性</h4> <p>对于软件设计来说，评审与其技术设计方法本身是一样重要的，评审对于研发项目的成功而言是绝对必要的。对设计进行评审是为了尽早发现软件的欠缺，尽可能把这些缺陷在进入下一阶段工作之前予以纠正，从而避免后期付出更多的代价。</p> <h4 id="优先级安排"><a href="#优先级安排" class="header-anchor">#</a> 优先级安排</h4> <p>设置优先级的关键是，划去清单中那些既不紧急也不重要的事项，找到那些既紧急又重要的事项，并进行优先处理，然后再去做剩下的那些或是紧急或是重要的事项。</p> <p>根据时间管理的经验，安排工作的原则顺序为：重要/紧急工作&gt;重要/不紧急&gt;不重要/紧急&gt;不重要/不紧急。</p> <h4 id="项目管理重要性"><a href="#项目管理重要性" class="header-anchor">#</a> 项目管理重要性</h4> <p>项目管理是核心能力之一。其他方面能力的积累也往往需要依靠项目管理能力的转化。譬如核心技术的积累，首先是基于最佳实践，而最佳实践只能依靠强有力的项目管理能力才能脱颖而出。而把最佳实践转化成解决方案，也是靠项目管理能力的支撑。最后再通过项目管理，把解决方案转化成核心技术产品或平台。</p> <p>项目管理的重要性，大致包含以下几条：</p> <ul><li><strong>项目进度把控</strong>——技术人员很容易犯的错误是技术优先，对项目的进展不太关注，而项目管理的目标就是要让这一点不出现问题。</li> <li><strong>支撑公司收入</strong>——无论是产品型公司，还是外包型公司，最终都在通过一个个项目的形式落地，来支撑公司收入。</li> <li><strong>人员工作安排</strong>——最好的方式是对工作进行拆分，每天的工作要能说清楚它的具体目标、要求标准等，这样才能让大家有存在感和参与感。</li></ul> <h4 id="产品质量的重要性"><a href="#产品质量的重要性" class="header-anchor">#</a> 产品质量的重要性</h4> <p>质量是一种管理，是一种控制，是一种预防。只有成熟的组织，成熟的团队，才能做出高水平的产品来。</p> <p>质量就是你的最高水平，以及你对用户理解的最高水平。你只有发挥出自己的最高水平，并且全身心投入，从根本上解决问题，才能带来更好的用户体验，更好的质量。</p> <h4 id="测试驱动开发"><a href="#测试驱动开发" class="header-anchor">#</a> 测试驱动开发</h4> <p>测试驱动开发（Test-Driven Development, TDD）是一种不同于传统软件开发流程的新型开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写测试能通过的功能代码，从而推动整个开发的进行。</p> <p>TDD优势：</p> <ul><li>TDD根据客户需求编写测试用例，对功能的过程和接口都进行了设计，而且这种从使用者角度对代码进行的设计通常更符合后期开发的需求。</li> <li>出于易测试和测试独立性的要求，这将促使我们实现松耦合的设计，并更多地依赖于接口而非具体的类，最终提高系统的可扩展性和抗变性。</li> <li>将测试工作提到编码之前，并频繁地运行所有测试，这样可以尽量地避免和尽早发现错误，极大地降低后续测试及修复的成本，也提高了代码的质量。</li> <li>TDD提供了持续的回归测试，使我们拥有重构的勇气，因为若代码的改动导致系统其他部分产生任何异常，测试都会立刻通知我们。</li> <li>TDD所产生的单元测试代码就是最完美的开发者文档，它们展示了所有的API该如何使用以及是如何运作的，而且它们与工作代码保持同步，永远是最新的。</li> <li>TDD可以减轻压力、降低忧虑，提高我们对代码的信心，使我们拥有重构的勇气，这些都是快乐工作的重要前提。</li> <li>提高了开发效率。</li></ul> <h4 id="编写高质量代码的难度"><a href="#编写高质量代码的难度" class="header-anchor">#</a> 编写高质量代码的难度</h4> <p>我们在设计面向对象代码的时候，不能仅仅以汉语的习惯去设计，而是要多找找有没有专门表达这个对象的英语名词。</p> <p>我们把类似的、重复的代码封装成子函数；用继承的方法来构建相似的数据对象。如果我们还能用恰如其分的名字来命名这些子函数和子类型，那么我们就能避免长篇累牍的重复代码，从而让代码更容易理解。</p> <p>代码重用的首要条件是代码可理解，而封装正是对复杂的实现过程进行屏蔽，让人可以快速理解。</p> <h4 id="事必躬亲的错误"><a href="#事必躬亲的错误" class="header-anchor">#</a> 事必躬亲的错误</h4> <p>事必躬亲是对员工智慧的扼杀，长此以往，员工容易形成惰性，责任心大大降低、技术能力止步不前。</p> <p>多让员工参与到需求讨论、软件设计中，这是对他们的肯定，也是满足员工自我价值实现的精神需要。赋予员工更多的责任和权力，他们会取得让你意想不到的成绩。</p> <h2 id="第4章-技术调研-预研"><a href="#第4章-技术调研-预研" class="header-anchor">#</a> 第4章 技术调研&amp;预研</h2> <h3 id="_4-1-概述"><a href="#_4-1-概述" class="header-anchor">#</a> 4.1 概述</h3> <h4 id="技术调研和预研的差别"><a href="#技术调研和预研的差别" class="header-anchor">#</a> 技术调研和预研的差别</h4> <p>技术调研是针对粗粒度需求实现方案进行的研究，很有可能对所需技术根本不清楚，需要通过调研项目来完成技术了解、技术选型、技术可行性分析、技术方案设计等工作。技术预研是针对细粒度需求的实现方案进行的预先尝试，主要针对的是通过技术调研所选择的技术，同时结合我们产品化时的实际需求，对实现时存在的不确定性因素、细节等进行预先研究、尝试，从而减小产品化过程中的技术实现风险。</p> <h4 id="参与调研和预研的重要性"><a href="#参与调研和预研的重要性" class="header-anchor">#</a> 参与调研和预研的重要性</h4> <p>对于一个技术负责人来说，职责范围内有许多工作，但更重要的是设计靠谱的技术方案。</p> <p>为了更好地设计系统、理解技术，你一定要组织调研项目和预研项目，这是因为技术发展非常快，只有针对技术进行调研、预研，才能够真正跟上技术发展的潮流。</p> <h3 id="_4-2-技术调研"><a href="#_4-2-技术调研" class="header-anchor">#</a> 4.2 技术调研</h3> <h4 id="技术调研思路"><a href="#技术调研思路" class="header-anchor">#</a> 技术调研思路</h4> <p><strong>1、了解动机</strong></p> <p>“了解需求”这是一个人尽皆知且每个人在技术调研前都会去做的一件事。</p> <p><strong>2、明确目的</strong></p> <p>明确本次调研项目可能涉及的具体技术内容，确定调研过程中需要对各个技术的差异点、技术实现原理进行总结，并通过测试数据、数据对比及原因分析，分析哪种技术或者框架适用于用户提出的实际需求。</p> <p><strong>3、确定步骤</strong></p> <p>1）尽量多地收集各种方案和资料；
2）迅速粗略地过一遍上述方案和资料，大体上总结出几种可能合适的方案；3）针对几种方案，一边调研每种方案，一边做笔记；
4）最后拿着笔记做最后的横向对比；
5）得出结论，同时因为做了笔记，反馈的素材也有了。</p> <p><strong>4、结论跟踪</strong></p> <p>1）简要说明下调研需求；
2）介绍跟需求相关的前置知识；
3）目前有哪些方案，具体分析各个方案的优缺点及适合的场景；
4）技术调研的结果是怎样的，不可行的话是因为什么，可行的话说说最终决定使用何种方案，并说说该方案跟其他方案比有何优势；
5）调研过程中碰到了哪些问题，如何解决；</p> <h4 id="调研过程"><a href="#调研过程" class="header-anchor">#</a> 调研过程</h4> <p><strong>1、需求整理</strong></p> <p>需要将业务需求转化为技术需求，从技术层面理解业务需求。
业务需求转化为技术需求后，最好可以组织一场内部的评审。</p> <p><strong>2、技术选型</strong></p> <p>首先明确该技术/框架所使用的需求范围，根据需求明确技术调研方向，然后通过技术评估手段进行选型，最终的选型结果需要需求提出方、技术调研方、技术专家代表等多个维度人员参与，以事实作为评判标准。</p> <p>我们的使命是使用创新技术并将它们应用在我们的软件开发过程中，并且能够解决新技术所带来的应用鸿沟，因此，标准、社区已经完善，大部分人都在使用了的技术是我们更好的选择。</p> <p><strong>3、明确方案</strong></p> <p>明确了技术选型，接下来，需要明确实现方案和测试方案。</p> <p><strong>实现方案</strong>——分为设计、编码两个步骤，首先需要针对通用场景和业务场景分别进行设计。</p> <p><strong>测试方案</strong>——测试场景分为通用测试场景和业务测试场景两部分，虽然分为两个测试场景，但是测试方案一般来说是一样的，差异点是执行场景、并发程度不同。</p> <p><strong>4、执行方案</strong></p> <p>需要执行测试用例。</p> <p>在通用测试场景下，我们需要按照业务的数据表形式，在各个调研数据库中分别创建这些数据表。</p> <p>在业务测试场景下，我们一般需要按照业务流程执行测试用例。</p> <p><strong>5、讨论结论</strong></p> <p>需要针对给定场景的对比测试结论进行分析并且描述清楚，列举每一项技术是否适用于我们设计的场景，并给出具体原因。</p> <p>需要进行总结，需要覆盖性能角度、技术评测角度、需求方角度、产品化角度以及其他因素等。</p> <h3 id="_4-3-技术预研"><a href="#_4-3-技术预研" class="header-anchor">#</a> 4.3 技术预研</h3> <h4 id="技术预研思路"><a href="#技术预研思路" class="header-anchor">#</a> 技术预研思路</h4> <p><strong>1、了解动机</strong></p> <p>立项预研项目一定是有背景存在的，大多数情况是当前的技术或者方案无法满足用户需求，或者一个全新的产品形态在产品经理脑海中出现，经过头脑风暴发现还存在若干技术或者方案选型难点，如果贸然立项，很有可能出现产品开发延期的情况。因此，需要在产品开发项启动前，明确存在疑惑的技术点。这时候，预研项目就可以启动了。</p> <p><strong>2、明确目的</strong></p> <p>首先需要了解用户需求，了解需求后，我们需要对现有系统进行剖析，接下来需要对当前情况进行解释。</p> <p>情况了解清楚之后，我们可以讨论、总结预研目的，例如提出一种新的系统架构方案、采用新的开源框架等，最终的目的是满足用户的需求。</p> <p><strong>3、确定步骤</strong></p> <p>预研项目一般来说分为以下几个步骤：</p> <p>1）搜索预研需求。
2）明确预研目的。
3）确定预研方案，需要针对各个方案进行各维度对比。
4）明确提出的方案是否适用于用户需求，若适用，可推荐进行产品化立项；若不适用，需找到备选方案继续预研。</p> <h4 id="预研过程"><a href="#预研过程" class="header-anchor">#</a> 预研过程</h4> <p><strong>1、技术介绍</strong></p> <p>明确预研需求之后，我们需要对所选择的方案或者技术进行介绍，也就是定义和综述。定义指的是对基本概念进行介绍，而综述指的是对当前该技术的发展及应用进行介绍。</p> <p><strong>2、明确方案</strong></p> <p>我们需要列举所有预期可能满足需求的解决方案，重点说明需要被本预研过程验证的一个或多个解决方案，并说明其各自的优缺点，以及提供潜在改进方向和应用可能性。</p> <p>采用哪种方案，不能只看技术先进性，还是需要结合自己的实际情况进行预研。</p> <p><strong>3、执行方案</strong></p> <p>第一步是方案列举，这一步需要做到深入理解。如果你对方案的实现原理不了解，那么无论怎么解释都是很空洞的。</p> <p>第二步是论证，需要从整体开始论证，逐渐下沉到各个重要模块。</p> <p>第三步是尝试推翻论证的结果，这一步建议召开部门内部评审会，让不同角色发声，你需要逐一解释。</p> <p><strong>4、讨论结论</strong></p> <p>预研工作的输出为技术可行性分析报告，输出的过程如下：</p> <p>1）根据公司技术规划和产品研发确定预研技术方向；
2）收集和整理有关预研技术的论文、专利、标准，了解预研技术的现状和未来发展方向；
3）对预研技术原理、技术方案进行全面、深入的分析，关键技术进行仿真和验证；
4）对研究成果进行总结，形成专利、标准提案；
5）编写预研技术可行性报告，为公司产品规划和研发提供决策依据。</p> <h3 id="_4-4-其他相关讨论"><a href="#_4-4-其他相关讨论" class="header-anchor">#</a> 4.4 其他相关讨论</h3> <h4 id="对技术发展的预估"><a href="#对技术发展的预估" class="header-anchor">#</a> 对技术发展的预估</h4> <p>作为一名技术团队的管理者，你必须了解当前技术发展趋势，并能够对趋势进行分析，进而明确自己团队未来1年、3年，甚至是5年、10年的发展目标。</p> <p>通过一些国外比较流行的科技网站来进行信息获取、知识学习，这些都有助于我们建立自己的知识储备体系，帮助我们完成对技术发展的预估。通过关注一些大咖或技术企业的公众号，了解最新的科技方向。还有就是技术峰会。</p> <h4 id="开源的好处"><a href="#开源的好处" class="header-anchor">#</a> 开源的好处</h4> <p>开源不仅意味着公司技术有了影响力，而且开源后技术需求的输入会变多，外部会给内部提供许多技术需求，从而通过从外部推进内部加快技术产出与技术创新。创新后再回归到开源，进而构成技术闭环。需求持续输入可让技术像产品一样迭代升级，提升功能单一的技术生命周期；需求多样化可以提高创新能力，从而让技术更有生命力。</p> <p>在获得影响力之后，简历的收集渠道会扩宽，会有同行主动给你发简历；同时也会给现在团队成员带来平台的成就感，也能让外界技术人员对团队成员产生认同感，这对于技术人员来说非常重要。</p> <h2 id="第5章-系统架构"><a href="#第5章-系统架构" class="header-anchor">#</a> 第5章 系统架构</h2> <h3 id="_5-1-系统架构工作"><a href="#_5-1-系统架构工作" class="header-anchor">#</a> 5.1 系统架构工作</h3> <h4 id="软件架构概念"><a href="#软件架构概念" class="header-anchor">#</a> 软件架构概念</h4> <p>软件架构就是通过对软件生命周期的拆分，在符合业务架构的前提下，达到软件本身访问增长目的的方式。</p> <p>软件架构离不开软件开发团队的组织架构，这个组织架构是软件开发生命周期和软件运行生命周期的执行者。</p> <p>如果软件开发团队的组织架构和业务的组织架构能一直保持高度一致，内部损耗就会达到最小，软件的架构会更简单，软件架构有效落地的可能性也会大幅度增加。</p> <p>架构追求的实际上是业务不断长大：通过对业务生命周期的拆分，突出并精简业务核心生命周期，弱化非核心生命周期，达到不同生命周期可以在空间和时间上并行，便于不同的人同时开展工作，提升业务人员单位时间内的产出。</p> <h4 id="软件架构师岗位"><a href="#软件架构师岗位" class="header-anchor">#</a> 软件架构师岗位</h4> <p>架构师都要有觉悟，理解并发现问题永远比解决问题更加重要，遇到问题首先进行分析，不要急于解决问题。</p> <p>软件架构师必须是一个组织的领导人，有权利调整这个组织的架构，才能够更好地发挥架构师的作用，才能够把软件开发生命周期、软件运行生命周期和业务生命周期的拆分落实执行。</p> <p>一名优秀的技术管理者，技术在前，管理在后，并不是说两者有太大的轻重差异，而是你需要花费70%的时间在技术上，只能花30%的时间在管理上，但是你需要用这30%的时间做完100%的管理工作。技术、管理，一样都不能差，架构能力也是一样。因此，一个好的开发团队领导就是一个很好的架构师。在架构师的领导下，这个组织一定是健康向上的。</p> <h4 id="软件架构师的责任"><a href="#软件架构师的责任" class="header-anchor">#</a> 软件架构师的责任</h4> <p>作为软件架构师，必须时刻把对软件生命周期和业务生命周期的识别放在第一位。软件生命周期的核心在于软件运行生命周期，以及围绕软件运行生命周期的拆分和组织，业务生命周期的核心在于围绕业务核心生命周期的拆分和组织。</p> <p>团队达到一定规模之后，技术管理者的大部公时间就需要花费在思考上面了，当然也可以继续编程，但是编程的目的是验证架构是否合理，所以不要受是否需要编程这一思维的束缚。如果设计得不好，那么团队就会走很多弯路，如果想要设计得很好，你必须自己或者带领团队做很多的测试、预研工作。</p> <h4 id="软件架构思路"><a href="#软件架构思路" class="header-anchor">#</a> 软件架构思路</h4> <p>软件架构师需要学会拆分生命周期，并且应该指导形成组织架构来落实架构的执行，需要平衡别人的利益，甚至去调整别人的利益。</p> <p>架构的目的就是为了增长，而要达到增长，就必须让很多人合作为完成同一件事情，并且使他们做的事情合并起来达到1+1&gt;2的效果，最少也要达到1+1=2的效果。从这一点来看，架构师要对总体增长的效果负责。</p> <h4 id="软件架构落地"><a href="#软件架构落地" class="header-anchor">#</a> 软件架构落地</h4> <p>架构师在做好架构拆分后，会形成不同的生命周期。针对不同的生命周期，要选择不同的技术来进行支撑，再把不同的生命周期分工交给不同类型的软件工程师去实现。这就是架构师和技术人员的分工配合，架构师负责拆分生命周期，技术人员负责实现生命周期。</p> <p>架构师思考技术时更多地需要考虑技术对生命周期拆分的支撑，以及不同技术实现拆分落地的成本和收益。以最少的成本达到更高的增长，这是每个架构师追求的目标，所以架构既不是技术的对立面，也不是技术的同一面，两者是相辅相成的关系。</p> <h3 id="_5-2-系统架构能力培养"><a href="#_5-2-系统架构能力培养" class="header-anchor">#</a> 5.2 系统架构能力培养</h3> <h4 id="提升驱动力"><a href="#提升驱动力" class="header-anchor">#</a> 提升驱动力</h4> <p>一个技术团队必须有自己的技术定位，也可以说是有技术愿景，明确了技术定位后，我们就需要制定团队技术能力的提升计划，特别是在系统架构能力的提升方面。而提升这些能力，又都需要有实际推动力。</p> <p>推动力可能来自以下三个方面：</p> <ul><li><strong>客户实际需求</strong>——业务需求是技术推动力。技术真正发挥价值的地方，一定是对用户产生影响的时候。</li> <li><strong>测试数据</strong>——业务发展到一定阶段都会遇到“飞机在全速飞行的前提下换引擎”的问题。</li> <li><strong>外部公司技术资料</strong>——多了解外部的技术发展状态，对于明确或纠正团队的技术发展方向很有利。</li></ul> <h4 id="学习能力"><a href="#学习能力" class="header-anchor">#</a> 学习能力</h4> <p>架构师是一个充满挑战的职业，知识面的宽窄往往决定着一个架构师的架构能力，你需要阅读大量的技术书籍，但是不要仅限于软件相关的书籍。要经常上技术论坛，一方面可以结交朋友，一方面可以拓展自己的知识面。</p> <p>从一个程序员到架构师是一个很大的变化，架构师需要从大的方面考虑，而不只是考虑这个模块该用哪种设计模式去开发。总的来说，想要成为架构师，需要有耐心，不断学习，拓宽自己的视野，不要局限于自己眼前的项目，多关注开源技术，多关注热门技术社区的新动向。</p> <h4 id="创新思维"><a href="#创新思维" class="header-anchor">#</a> 创新思维</h4> <p>创新实在是一项艰巨的工作，概念的建立不是一蹴而就的，需要反复地推敲、对比、自我否定。问题的定义更是自我意识游走在理想与现实之间，尝试各种问题边界的可能，不断地进行权衡。人生贵在坚持批判性思维，而不是简单的批评与抱怨。所有这些行动都是很困难的，因为它们会产生巨大的认知摩擦。</p> <p>可以将创新模型简单地归纳为以下4个核心要素：</p> <ul><li>创新需要挑战现状，即批判性思维。</li> <li>批判性思维需要准确的问题定义。</li> <li>问题的定义有赖于概念系统的建立。</li> <li>在初始阶段，概念模型的正确与否是次要的，更为重要的是要有一个概念模型，然后这个概念模型可以随着认识的深入而不断演化。</li></ul> <h3 id="_5-3-常见问题分析"><a href="#_5-3-常见问题分析" class="header-anchor">#</a> 5.3 常见问题分析</h3> <h4 id="无从入手"><a href="#无从入手" class="header-anchor">#</a> 无从入手</h4> <p>出现无从下手或者随意下手的情况，真正的原因都是不理解，建议大家从软件系统架构基础类的书学起，不要一开始就看基于潮流框架的架构书
架构师需要参与到项目开发中，这样团队成员就不会出现轻视设计的情况。</p> <h4 id="技术优先"><a href="#技术优先" class="header-anchor">#</a> 技术优先</h4> <p>架构师需要很冷静、很平等地对待所有的技术。对于软件架构师来说，他们要深刻地领会软件开发生命周期和软件运行生命周期，以及业务的生命周期，并把它们合理地组织、结合在一起，能够通过软件的快速增长来支撑和顺应业务的增长。这些是软件架构师的核心能力。为达到这些目标，无论是新的还是旧的技术、先进的还是落后的技术，只要场景合适，他们就会采纳。因为架构师是技术的使用者，他们把技术当作解决增长问题的手段和工具，而不会被技术束缚住。</p> <h4 id="业务困境"><a href="#业务困境" class="header-anchor">#</a> 业务困境</h4> <p>对于做软件的技术人员而言，技术也可以分为两部分：一部分是软件技术，另一部分是业务技术。因此在谈技术时，只谈软件技术是远远不够的。不管是软件技术还是业务技术，均来源于对现实生活问题的解决，现实生活才是架构师真正的营养来源。</p> <p>软件架构师把完成业务的工作当成自己的最大利益，深入到业务中去。对业务领域理解得越深入，就越知道如何去发现问题，慢慢就成为业务专家了。只有做到这一点，才能在业务领域建立自信，成为一个合格的软件架构师。</p> <p>做架构的人必须亲身体验业务，感受业务，才可能真正认识业务的个性，真正认识业务所面临的问题。在理解业务个性的基础上，才能够谈共性。否则这个抽象就像是无根之木，一旦局限于个人的主观认识，很难长大。</p> <h4 id="一步到位思想"><a href="#一步到位思想" class="header-anchor">#</a> 一步到位思想</h4> <p>既没有必要一步到位，也不可能一步到位。只能结合运维和运营，及时地探索流量的增长，在流量达到瓶颈之前，根据业务的规律进行合理的拆分，帮助快速地应对增长。</p> <h4 id="系统过度设计问题"><a href="#系统过度设计问题" class="header-anchor">#</a> 系统过度设计问题</h4> <p>设计的方案如果不结合目前的实际情况，考虑得太复杂，实现起来也会特别复杂，和造轮子一样，也存在同样的浪费，其实过度设计倒还好，就怕错误设计。</p></div></div> <!----> <div class="page-edit"><!----> <div class="tags"><a href="/brennan-wu-blog/tags/?tag=%E9%A2%86%E5%AF%BC%E5%8A%9B" title="标签">#领导力</a></div> <div class="last-updated"><span class="prefix">上次更新:</span> <span class="time">2023/04/26, 07:29:08</span></div></div> <div class="page-nav-wapper"><div class="page-nav-centre-wrap"><a href="/brennan-wu-blog/pages/b08d0e/" class="page-nav-centre page-nav-centre-prev"><div class="tooltip">《软技能-代码之外的生存指南》读书笔记</div></a> <a href="/brennan-wu-blog/pages/3b0243/" class="page-nav-centre page-nav-centre-next"><div class="tooltip">《程序员修炼之道：从小工到专家》读书笔记</div></a></div> <div class="page-nav"><p class="inner"><span class="prev">
        ←
        <a href="/brennan-wu-blog/pages/b08d0e/" class="prev">《软技能-代码之外的生存指南》读书笔记</a></span> <span class="next"><a href="/brennan-wu-blog/pages/3b0243/">《程序员修炼之道：从小工到专家》读书笔记</a>→
      </span></p></div></div></div> <div class="article-list"><div class="article-title"><a href="/brennan-wu-blog/archives/" class="iconfont icon-bi">最近更新</a></div> <div class="article-wrapper"><dl><dd>01</dd> <dt><a href="/brennan-wu-blog/pages/8a0173/"><div>
            职业路线：前端工程师的晋升逻辑到底是什么
            <!----></div></a> <span class="date">05-02</span></dt></dl><dl><dd>02</dd> <dt><a href="/brennan-wu-blog/pages/c002a8/"><div>
            《从技术走向管理：李元芳履职记》读书笔记
            <!----></div></a> <span class="date">04-15</span></dt></dl><dl><dd>03</dd> <dt><a href="/brennan-wu-blog/pages/2641af/"><div>
            解读《真希望我父母读过这本书》
            <!----></div></a> <span class="date">11-28</span></dt></dl> <dl><dd></dd> <dt><a href="/brennan-wu-blog/archives/" class="more">更多文章&gt;</a></dt></dl></div></div></main></div> <div class="footer"><div class="icons"><a href="mailto:985979261@qq.com" title="发邮件" target="_blank" class="iconfont icon-juchangxinxiang"></a><a href="https://github.com/wyd112821" title="GitHub" target="_blank" class="iconfont icon-github"></a><a href="https://gitee.com/wuyadong112821" title="gitee" target="_blank" class="iconfont icon-gitee"></a></div> 
  Theme by
  <a href="https://github.com/xugaoyi/vuepress-theme-vdoing" target="_blank" title="本站主题">Vdoing</a> 
    | Copyright © 2022-2023
    <span>Brennan Wu | <a href="https://github.com/xugaoyi/vuepress-theme-vdoing/blob/master/LICENSE" target="_blank">MIT License</a></span></div> <div class="buttons"><div title="返回顶部" class="button blur go-to-top iconfont icon-262" style="display:none;"></div> <div title="去评论" class="button blur go-to-comment iconfont icon-pinglun" style="display:none;"></div> <div title="主题模式" class="button blur theme-mode-but iconfont icon-43_zhuti"><ul class="select-box" style="display:none;"><li class="iconfont icon-zidong">
          跟随系统
        </li><li class="iconfont icon-rijianmoshi">
          浅色模式
        </li><li class="iconfont icon-yejianmoshi">
          深色模式
        </li><li class="iconfont icon-yuedu">
          阅读模式
        </li></ul></div></div> <!----> <!----> <!----></div><div class="global-ui"></div></div>
    <script src="/brennan-wu-blog/assets/js/app.422e2e24.js" defer></script><script src="/brennan-wu-blog/assets/js/2.372f0770.js" defer></script><script src="/brennan-wu-blog/assets/js/3.22a0f36b.js" defer></script><script src="/brennan-wu-blog/assets/js/27.b3041988.js" defer></script>
  </body>
</html>
